\chapter{Introduction}
\label{cap:Introduction} 
\section{Purpose}
This document aims to explain how SWIMv2 general architecture should be. With this documet we are about to give an idea about how this application will result once it is implemented.
Notice that this document won't show the technical implementation details but it will just give an high level view of the application design, that is how it should appear once ended.

\section{Scope}
The whole application design have been made according to the functionalities explained in the RASD document and taking in to account all the functional requirements.

\noindent
Here there's a quick recap of the macro functionalities:

\begin{itemize}
 \item Support different kind of users, such as normal ones, admin and founder.
 \item Provide the possibility to have a personal page with public information as own skills, and to add friends.
 \item Provide a search tool (among the whole system and among friends)
 \item Provide feedback once got an help of a kind
\end{itemize}

According to this macro functionalities we designed the database of the web app, how the web site is organized so how it will be navigated and an explanation of the business logic we designed.

\section{References}
We used the following document to develop the DD: 
\begin{itemize}
 \item swKnights-swimv2-rasd-v2.pdf
 \item http://docs.oracle.com/javaee/
\end{itemize}

\section{Summary}
This document try to follow as much as possible the IEEE-1016-2009 for the Design Software Document.
We substantially divided the document in Viewpoint and for each one, where interesting for the applicative part of the project, we describe more sub-views which emphasize some aspects of the general view.

For this application we identified four interesting Viewpoint:

\begin{description}
	\item[Component Viewpoint]: indicates which are the subsystems and their components, more this view indicates how this subsystems are mapped on the various applicative tiers.
	\item[Information Viewpoint]: deals the data persistence handling and how data are mapped both in the database and in the central memory when they are used by the application.
	\item[Interface Viewpoint]: shows how the user interface have been projected and how it interfaces in turn to the business logic.
	\item[StateDynamicsViewpoint]: shows some fundamental aspects of the application elements state. 
\end{description}

We underline the fact that we prefer a compact representation of the system instead of a decomposition in sub-diagrams, for some fundamental reasons:

\begin{enumerate}
	\item even if less clear, they give a set vision.
	\item subdiagrams risk to emphasize too much the implementative aspects that, even if important, they have to be set a part, maybe using them to motivate design choices and additional diagram presence. 
	\item there's the risk to decompose in not significant subsets
	\item there's the risk to work in vain, work that could be upset by the effective implementation
	\item we thought a life-cycle close to scrim, where after compiling the functionality list, we implement step by step, organizing all the worl and the design at the moment. Planning too in details is an opposite idea to agile life-cycles.
	\item small diagram are not significant if taken singly.

\end{enumerate}

However we try to maintain a modular approach to the design, and where the diagram are not modular for nature, we highlighted in words the fundamental components.
